home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc799.txt < prev    next >
Text File  |  1994-08-01  |  14KB  |  294 lines
  1. Network Working Group                                     D. L. Mills
  2. Request for Comments:  799                        COMSAT Laboratories
  3.                                                        September 1981
  4.  
  5.  
  6.                        Internet Name Domains
  7.  
  8.  
  9. 1.  Introduction
  10.  
  11.      In the long run, it will not be practicable for every internet
  12. host to include all internet hosts in its name-address tables.  Even
  13. now, with over four hundred names and nicknames in the combined
  14. ARPANET-DCNET tables, this has become awkward.  Some sort of
  15. hierarchical name-space partitioning can easily be devised to deal
  16. with this problem; however, it has been wickedly difficult to find one
  17. compatible with the known mail systems throughout the community.  The
  18. one proposed here is the product of several discussions and meetings
  19. and is believed both compatible with existing systems and extensible
  20. for future systems involving thousands of hosts.
  21.  
  22. 2.  General Topology
  23.  
  24.      We first observe that every internet host is uniquely identified
  25. by one or more 32-bit internet addresses and that the entire system is
  26. fully connected.  For the moment, the issue of protocol compatibility
  27. will be ignored, so that all hosts can be assumed MTP-competent.  We
  28. next impose a topological covering on the space of all internet
  29. addresses with a set of so-called name domains.  In the natural model,
  30. name domains would correspond to institutions such as ARPA, UCL and
  31. COMSAT, and would not be necessarily disjoint or complete.  While in
  32. principle name domains could be hierarchically structured, we will
  33. assume in the following only a single-level structure.
  34.  
  35.      Every name domain is associated with one or more internet
  36. processes called mail forwarders and the name of that domain is the
  37. name for any of these processes.  Each forwarder process for a
  38. particular domain is expected to maintain duplicate name-address
  39. tables containing the names of all hosts in its domain and, in
  40. addition, the name of at least one forwarder process for every other
  41. domain.  Forwarder processes may be replicated in the interests of
  42. robustness; however, the resulting complexities in addressing and
  43. routing will not be discussed further here.  A particular internet
  44. host may support a number of forwarder processes and their collective
  45. names represent nicknames for that host, in addition to any other
  46. names that host may have.  In the following an internet host
  47. supporting one or more forwarder proceses will be called simply a
  48. forwarder.
  49.  
  50.      Every host is expected to maintain name-address tables including
  51. the names of at least one forwarder for every
  52.  
  53.  
  54. Internet Name Domains                               PAGE   2
  55.  
  56.  
  57.  
  58. domain together with additional hosts as convenient.  A host may
  59. belong to several domains, but it is not necessary that all hosts in
  60. any domain, be included in its tables.  Following current practice,
  61. several nicknames may be associated with the principal name of a host
  62. in any domain and these names need not be unique relative to any other
  63. domain.  Furthermore, hosts can be multi-homed, that is, respond to
  64. more than one address.  For the purpose of mail forwarding and
  65. delivery, we will assume that any of these addresses can be used
  66. without prejudice.  The use of multi-homing to facilitate source
  67. routing is a topic for future study.
  68.  
  69. 3.  Naming Conventions
  70.  
  71.      In its most general form, a standard internet mailbox name has
  72. the syntax
  73.  
  74.                   <user>.<host>@<domain> ,
  75.  
  76. where <user> is the name of a user known at the host <host> in the
  77. name domain <domain>.  This syntax is intended to suggest a
  78. three-level hierarchically structured name (reading from the right)
  79. which is unique throughout the internet system.  However, hosts within
  80. a single domain may agree to adopt another structure, as long as it
  81. does not conflict with the above syntax and as long as the forwarders
  82. for that domain are prepared to make the requisite transformations.
  83. For instance, let the name of a domain including DCNET be COMSAT and
  84. the name of one of its hosts be COMSAT-DLM with Mills a user known to
  85. that host.  From within the COMSAT domain the name Mills@COMSAT-DLM
  86. uniquely identifies that mailbox as could, for example, the name
  87. Mills.COMSAT-DLM@COMSAT from anywhere in the internet system.
  88. However, Mills@COMSAT-DLM is not necessarily meaningful anywhere
  89. outside the COMSAT domain (but it could be).
  90.  
  91.      A typical set of name domains covering the current internet
  92. system might include ARPA (ARPANET), COMSAT (DCNET), DCA (EDNET,
  93. WBNET), UCL (UCLNET, RSRENET, SRCNET), MIT (CHAOSNET), INTELPOST
  94. (INTELPOSTNET) and the various public data networks.  The ARPA
  95. forwarder would use a name-address table constructed from the latest
  96. version of the HOSTS.TXT table in the NIC data base.  The other
  97. forwarders would construct their own, but be expected to deposit a
  98. copy in the NIC data base.
  99.  
  100. 4.  Mail Transport Principles
  101.  
  102.      In the interests of economy and simplicity, it is expected that
  103. the bulk of all mail transport in the internet system will take place
  104. directly from originator to recipient
  105.  
  106.  
  107. Internet Name Domains                               PAGE   3
  108.  
  109.  
  110.  
  111. host and without intermediate relay.  A technique of caching will
  112. probably be necessary for many hosts in order to reduce the traffic
  113. with forwarders merely to learn the internet address associated with a
  114. correspondent host.  This naturally encourages naming strategies
  115. designed to minimize duplicate names in the various domains; however,
  116. such duplicates are not forbidden.
  117.  
  118.      There are several reasons why some messages will have to be
  119. staged at an intermediate relay, among them the following:
  120.  
  121. 1.  It may not be possible or convenient for the  originator
  122.     and recipient hosts to be up on the internet system at
  123.     the same time for the duration of the transfer.
  124.  
  125. 2.  The originator  host  may  not  have  the  resources  to
  126.     perform all name-address translations required.
  127.  
  128. 3.  A direct-connection path may  not  be  feasible  due  to
  129.     regulatory economic or security constraints.
  130.  
  131. 4.  The originator and recipient hosts may not recognize the
  132.     same lower-level transport protocol (e.g.  TCP and NCP).
  133.  
  134.      A mail relay is an internet process equipped to store an MTP
  135. message for subsequent transmission.  A mail forwarder is a mail
  136. relay, but not all relays are forwarders, since they might not include
  137. the full name-address capability required of forwarders.  In addition,
  138. relays may not be competent in all domains.  For instance, a MTP/TCP
  139. relay may not understand NCP.  In other words, the forwarders must be
  140. fully connected, but the relays may not.
  141.  
  142.      The particular sequence of relays traversed by a message is
  143. determined by the sender by means of the source route specification in
  144. the MRCP command.  There are several implications to this:
  145.  
  146. 1.  Advisory messages returned to the originator by a relay
  147.     or recipient host are expected to traverse the route in
  148.     reverse order.
  149.  
  150. 2.  Relay host names follow the same  naming  convention  as
  151.     all  host  names relative to their domain.  Since it may
  152.     not be possible (see below) to use internet addresses to
  153.     dis-ambiguate the domain, the complete standard internet
  154.     name .<host>@<domain> is required everywhere.
  155.  
  156. 3.  There is no current  provision  for  strict/loose  route
  157.     specifications.    If,  in  fact,  the  "ordinary"  host
  158.     specification @<host> were used, each relay or forwarder
  159.  
  160. Internet Name Domains                               PAGE   4
  161.  
  162.  
  163.  
  164.     would  use  the  rules  outlined in the next section for
  165.     routing.  This may result in additional relay hops.
  166.  
  167. 5.  Forwarder Operations
  168.  
  169.      This section describes a likely scenario involving hosts, relays
  170. and forwarders and typical internet routes.  When a forwarder receives
  171. a message for <user>.<host>@<domain>, it transforms <host> if
  172. necessary and forwards the message to its address found in the
  173. name-address table for <domain>.  Note that a single host can be a
  174. forwarder for several independent domains in this model and that these
  175. domains can intersect.  Thus, the names Mills@USC-ISIE,
  176. Mills.USC-ISIE@ARPA and Mills.USC-ISIE@COMSAT can all refer to the
  177. same mailbox and the names USC-ISIE, ARPA and COMSAT can, conceivably,
  178. all be known in the same domain.  Such use would be permissable only
  179. in case the name USC-ISIE did not conflict with other names in this
  180. domain.
  181.  
  182.      In order for this scheme to work efficiently, it is desireable
  183. that messages transiting forwarders always contain standard internet
  184. mailbox names.  When this is not feasible, as in the current ARPANET
  185. mail system, the forwarder must be able to determine which domain the
  186. message came from and edit the names accordingly.  This would be
  187. necessary in order to compose a reply to the message in any case.
  188.  
  189.      In the RFC-780 model a message arriving at a forwarder is
  190. processed by the MTP server there.  The server extracts the first
  191. entry in the recipient-route field of an MRCP command.  There are two
  192. cases, depending on whether this entry specifies a domain name or a
  193. host name.  If a domain name, as determined by a search of a universal
  194. table, it refers to one of the domains the server represents.  If not,
  195. it must a name or nickname of the server's host relative to ooe of the
  196. domains to which the sender belongs.  This allows a distinction to be
  197. made between the domains COMSAT and INTELPOST on one hand and the
  198. COMSAT host COMSAT-PLA on the other, all of which might be represented
  199. by the same internet address, and implies that domain names must be
  200. unique in all domains.
  201.  
  202.      The server next extracts the second entry in the recipient-route
  203. field of the MRCP command and resolves its address relative to the
  204. domain established by the first entry.  If the second entry specifies
  205. an explicit domain, then that overrides the first entry.  If not and
  206. the first entry specifies a domain, then that domain is effective.
  207. However, if the first entry specifies the server's host, it may not be
  208. apparent which domain is intended.  For instance, consider the
  209. following two MRCP commands:
  210.  
  211. Internet Name Domains                               PAGE   5
  212.  
  213.  
  214.  
  215. MRCP to:<@COMSAT,Mills@HOST> and 
  216. MRCP to:<@INTELPOST,Mills@HOST> ,
  217.  
  218. where Mills.HOST@COMSAT and Mills.HOST@INTELPOST are distinct
  219. mailboxes on different hosts.  A receiving host supporting forwarders
  220. for both COMSAT and INTELPOST can then preserve this distinction and
  221. forward correctly using the above rules.
  222.  
  223.      Now let the forwarder host have the name FORWARDER in both the
  224. COMSAT and INTELPOST domains and consider its options when receiving
  225. the command
  226.  
  227. MRCP to:<@FORWARDER,Mills@HOST> .
  228.  
  229. The forwarder is being asked simply to relay within the domain of the
  230. sender; however, it belongs to more than one domain! The obvious way
  231. to resolve this issue would be to forbid the use of implicit domains,
  232. as represented by Mills@HOST, and require the full internet mailbox
  233. names Mills.HOST@COMSAT or Mills.HOST@INTELPOST.  It is also possible
  234. to dis-ambiguate the domain by inspecting the first entry of the
  235. sender-route field of the MAIL command (see below).
  236.  
  237. 6.  Source and Return Routing
  238.  
  239.      In the RFC-780 model, routes can be specified in the
  240. recipient-route field of the MRCP command and in the sender-route
  241. field of the MAIL command.  In point of fact, neither the
  242. recipient-route or sender-route is necessary if the originator
  243. specifies standard internet mailbox names.  So long as the routes,
  244. when used, consist only of domain names, there is no conflict with the
  245. current RFC-780 specification.  If for some reason forwarding must be
  246. done via other hosts, then the use of a complete and unambigous syntax
  247. like .<host>@<domain> is required in order to avoid problems like that
  248. described above.
  249.  
  250.      The present RFC-780 specification requires the receiver to
  251. construct a name for the sender and insert this at the beginning of
  252. the sender-route.  Presumably, the only information it has to
  253. construct this name is the internet address of the sender.  Consider
  254. the case, as in the example above, where multiple domains are
  255. supported by a single server on a particular host.  If hosts receiving
  256. a message relayed via that server were to map its address into a name,
  257. there would be no way to determine which domain was intended.  We
  258. conclude that the sending host must update the sender-route as well as
  259. the recipient-route.  It does this simply by copying the first entry
  260. in the recipient-route as received as the new first entry in the
  261. sender-route.
  262.  
  263. Internet Name Domains                               PAGE   6
  264.  
  265.  
  266.  
  267. 7.  Editing the RFC-733 Header
  268.  
  269.      Every effort should be made to avoid editing the RFC-733 header,
  270. since this is an invasive procedure requiring extensive analysis.  It
  271. is expected that newly developed mail systems will be aware of the
  272. standard internet mailbox syntax and ensure its use everywhere in the
  273. RFC-733 and RFC-780 fields.  On the occasions where this is not
  274. possible, such as in many current ARPANET hosts, the necessary editing
  275. should be performed upon first entry to the internet mail system from
  276. the local mail system.  This avoids the problems mentioned above and
  277. simplifies reply functions.
  278.  
  279.      In the case of ARPANET hosts, the editing operations assume that
  280. all names in the form <anything>@<domain>, where <domain> is the name
  281. of a domain, are unchanged.  Names in the form <anything>@<host>,
  282. where <host> is the name of a host in the ARPA domain, are transformed
  283. to the form <anything>.<host>@ARPA.  Anything else is an error.
  284. Before handing off to an ARPANET NCP mailer, an ARPA MTP forwarder
  285. might optionally transform <anything>.<host>@ARPA to <anything>@<host>
  286. in order to reduce the forwarder traffic when local mail systems are
  287. available.  Similar situations might exist elsewhere.
  288.  
  289. 8.  Concluding Remarks
  290.  
  291.      This memorandum is intended to stimulate discussion, not simulate
  292. it. 
  293. -------
  294.